1. Technical Field
This invention generally relates to the data processing field. More specifically, this invention relates to the field of object creation in object oriented systems.
2. Background Art
Since the dawn of the computer age, overall computer system technology has evolved and progressed through advances in both hardware performance and software programming techniques. As the complexity of computer hardware and software increases, the need to efficiently and effectively develop new software becomes more acute. Software development costs have continued to rise because complex programs take more time, and hence more money, to produce. Object oriented programming (OOP) is one way computer programmers have sought to reduce the time and costs associated with developing complex software. A single object in OOP represents an individual operation or a group of operations that are performed by a computer system upon information controlled by the object. Objects can be thought of as autonomous agents that work together to perform certain tasks. Sometimes entire computer programs are made up of groupings of objects and sometimes objects are simply accessed by more traditional computer programs to perform one specific task or subtask.
The goal of using object oriented programming is to create small, reusable sections of program code known as objects that can be quickly and easily combined and re-used to create new programs. This is similar to the idea of using the same set of building blocks again and again to create many different structures. The modular and reusable aspects of objects will typically speed development of new programs, thereby reducing the costs associated with the development cycle. In addition, by creating and re-using a group of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
Although object oriented programming offers significant improvements over other programming types, program development still requires significant amounts of time and effort, especially if no preexisting objects are available as a starting point. Consequently, one approach has been to provide a program developer with a set of pre-defined, interconnected classes that create a set of objects. Such pre-defined classes and libraries are typically called object frameworks. Frameworks essentially provide a prefabricated structure for a working program by defining certain classes, class relationships, and methods that a programmer may easily use by appropriate subclassing to generate a new object oriented program.
A problem, though, that exists with any object oriented program is the difficulty of modifying the configuration of a specific object (by modifying its class definition) to fit a specific need, improve the program, or alternate between two or more implementations of that program. Each object oriented class is characterized by configuration data that defines attributes of the class. Changing the way objects that are members of a class behave requires changing the configuration data for that class. The most common way of changing an object oriented (OO) program so that the program uses a different class implementation than the existing class, would require changing the source code wherever the code creates the objects, rebuilding the program, and installing the program on all the systems intended to use the new class. If there are many different sets of such classes that could be changed, or various physical locations for creation of the objects, the combinatorial explosion of different versions of the program becomes completely unmanageable.
To address this problem, a known method for class replacement has been implemented that uses class configuration data that is separate from and external to a class, and can thus be changed to create a new replacement class without rebuilding the program. This approach has been used in the San Francisco framework developed by IBM. The class replacement in the San Francisco framework uses keys known as tokens that are stored in a table of configuration data along with the class names that correspond to each token. When an instance of a class is needed, its token is passed to a factory object, which determines from the configuration data the class that corresponds to the token, and instantiates an instance of that class.
One problem with the class replacement approach used in the San Francisco framework is that the configuration data is global to the object oriented system. Sometimes it is desirable to have class configurations that vary according to a specific processing context or environment. For example, a company may have different divisions, and each division may use its own specific way of performing currency conversions for transactions. These different divisions need a way to perform class replacement that is based to their processing environment, which is not currently supported in version 1.4.4 of the San Francisco framework. There are ways to retrieve context information in the San Francisco framework, but no way to base the class replacement according to this context information. Without an apparatus and methods for easily changing configuration data in an object oriented system to perform context-based class replacement, the computer industry will have to endure the limitations of prior art class replacement techniques.